OpenWRT ルータとして2年使い続けている NanoPi R2S の SD カードのファイルシステムに破損が目立つようになったことから、定期生成しているオンラインバックアップ イメージ を検証の上、新しいメディアに書き込んで入れ替えました。
OpenWRTを入れたSDにファイルシステムエラーが発生
FriendlyElec NanoPi R2SをOpenWRTルータとして使い始めて2年、OpenWRTを入れたmicro SDのファイルシステムが壊れつつあるのか、起動時にrootfsが読み取り専用で立ち上がることが何度かありました。
これは、元々怪しげなノンブランドメディアを使っていることに加え、Cloud対応版のNetdataを導入したことで、容量が逼迫した状態でストレージへのI/Oが高くなったことが原因でしょう。
Cloud版Netdataのログを内包するには、さすがにもう少し余裕のあるストレージメディアに入れ替えた方が良さそうです。
ちなみに、OpenWRTパッケージ版のNetdataは（導入記事はこちら）、スタンドアロン動作に限った仕様でビルドされています。
SDオンラインバックアップイメージをマウントして検証と修復
このシステムは定期的にNASへのイメージバックアップをオンライン生成しているので、
このイメージを新しいメディアへ書き込んで使い物になるのか、Ubuntu 18.04デスクトップ上でループデバイスに登録して検証します（手順は以前の記事を参照）。
ローカルへコピーしたイメージアーカイブを解凍して、パーティション構造を確認。
|
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 |
$ gunzip -k ./R2S.img.gz $ ls -l -rw-r--r-- 1 user user 1007681536 Jan 16 08:45 R2S.img -rw-r--r-- 1 user user 382391678 Jan 16 08:45 R2S.img.gz $ sudo fdisk -lu R2S.img ディスク R2S.img: 961 MiB, 1007681536 バイト, 1968128 セクタ 単位: セクタ (1 * 512 = 512 バイト) セクタサイズ (論理 / 物理): 512 バイト / 512 バイト I/O サイズ (最小 / 推奨): 512 バイト / 512 バイト ディスクラベルのタイプ: dos ディスク識別子: 0x7ac9d3f4 デバイス 起動 開始位置 最後から セクタ サイズ Id タイプ R2S.img1 * 65536 98303 32768 16M 83 Linux R2S.img2 131072 1769471 1638400 800M 83 Linux $ sudo partx -s R2S.img NR START END SECTORS SIZE NAME UUID 1 65536 98303 32768 16M 7ac9d3f4-01 2 131072 1769471 1638400 800M 7ac9d3f4-02 |
ループデバイスへ登録。
|
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 |
$ losetup -f /dev/loop26 $ sudo partx -v -a R2S.img パーティション: none, ディスク: R2S.img, 下限: 0, 上限: 0 ループバックデバイスとして '/dev/loop26' を使用しようとしています /dev/loop26: パーティション情報のタイプ 'dos' を検出しました range recount: max partno=2, lower=0, upper=0 /dev/loop26: パーティション #1 を追加しました /dev/loop26: パーティション #2 を追加しました $ sudo fdisk -lu /dev/loop26 ディスク /dev/loop26: 961 MiB, 1007681536 バイト, 1968128 セクタ 単位: セクタ (1 * 512 = 512 バイト) セクタサイズ (論理 / 物理): 512 バイト / 512 バイト I/O サイズ (最小 / 推奨): 512 バイト / 512 バイト ディスクラベルのタイプ: dos ディスク識別子: 0x7ac9d3f4 デバイス 起動 開始位置 最後から セクタ サイズ Id タイプ /dev/loop26p1 * 65536 98303 32768 16M 83 Linux /dev/loop26p2 131072 1769471 1638400 800M 83 Linux |
両パーティションに fsck を掛けてみると、やはり rootfs に大量の問題点が摘出されるも、全て回復できた模様。
|
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 |
$ sudo fsck -fy /dev/loop26p1 fsck from util-linux 2.31.1 e2fsck 1.44.1 (24-Mar-2018) Pass 1: Checking iノードs, blocks, and sizes Pass 2: Checking ディレクトリ structure Pass 3: Checking ディレクトリ connectivity Pass 4: Checking reference counts Pass 5: Checking グループ summary information kernel: 14/1024 files (0.0% non-contiguous), 2983/4096 blocks user@WS-0300u:/str500/conv9$ sudo fsck -fy -t ext4 /dev/loop26p2 fsck from util-linux 2.31.1 e2fsck 1.44.1 (24-Mar-2018) Pass 1: Checking iノードs, blocks, and sizes Iノード 19998 has corrupt extent header. Clear inode? yes Iノード 19998 is a zero-length ディレクトリ. クリア? yes Iノード 19999 has corrupt extent header. Clear inode? yes Iノード 19999, i_blocks is 8, should be 0. 修正? yes Iノード 20000 has a bad extended attribute block 32. クリア? yes Iノード 20000 has an invalid extent (logical block 0, invalid physical block 35184372188864, len 32) クリア? yes - 略 - Free iノードs count wrong (41685, counted=41574). 修正? yes rootfs: ***** ファイルシステムは変更されました ***** rootfs: 5018/46592 files (4.2% non-contiguous), 160108/204800 blocks $ ls -l -rw-r--r-- 1 user user 1007681536 Jan 19 14:08 R2S.img -rw-r--r-- 1 user user 382391678 Jan 16 08:45 R2S.img.gz |
イメージファイルのタイムスタンプが更新されているのを確認して、ループデバイスの後始末。
|
1 2 3 4 5 6 7 |
$ sudo partx -v -d /dev/loop26 パーティション: none, ディスク: /dev/loop26, 下限: 0, 上限: 0 /dev/loop26: パーティション #1 を削除しました /dev/loop26: パーティション #2 を削除しました $ sudo losetup -d /dev/loop26 $ sudo losetup -f /dev/loop26 |
balenaEtcherで少し大きなSDへ書き込みと拡張
前回同様、少容量のジャンクmicro SDを淘寶で購入。今回は2GBメディアにしたところ、届いたのは2GBだけFAT32フォーマットされた4GBメディアでした。ジャンクSD界隈でもとうとう最低容量4GB〜なのかもしれません。
図1.2GBを謳いながら実は4GBなジャンクSD
一度きれいさっぱり初期化させた後、 dd コマンドでイメージを書き込んでみるも、読み取れないことがあったのでbalenaEtcherで書き込み。
図2.balenaEtcherで書き込み
そのままGPartedで容量を800MB→1800MBへとリサイズします。
図3.GPartedでパーティション拡張
出来上がった新メディアを fsck に掛け、問題ないことを確認。
|
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 |
$ sudo fdisk -l /dev/sdd ディスク /dev/sdd: 3.8 GiB, 4026531840 バイト, 7864320 セクタ 単位: セクタ (1 * 512 = 512 バイト) セクタサイズ (論理 / 物理): 512 バイト / 512 バイト I/O サイズ (最小 / 推奨): 512 バイト / 512 バイト ディスクラベルのタイプ: dos ディスク識別子: 0x7ac9d3f4 デバイス 起動 開始位置 最後から セクタ サイズ Id タイプ /dev/sdd1 * 65536 98303 32768 16M 83 Linux /dev/sdd2 131072 3817471 3686400 1.8G 83 Linux $ sudo fsck -fy /dev/sdd1 fsck from util-linux 2.31.1 e2fsck 1.44.1 (24-Mar-2018) Pass 1: Checking iノードs, blocks, and sizes Pass 2: Checking ディレクトリ structure Pass 3: Checking ディレクトリ connectivity Pass 4: Checking reference counts Pass 5: Checking グループ summary information kernel: 14/1024 files (0.0% non-contiguous), 2983/4096 blocks $ sudo fsck -fy -t ext4 /dev/sdd2 fsck from util-linux 2.31.1 e2fsck 1.44.1 (24-Mar-2018) Pass 1: Checking iノードs, blocks, and sizes Iノード 7, i_size is 33615872, should be 33624064. 修正? yes Pass 2: Checking ディレクトリ structure Pass 3: Checking ディレクトリ connectivity Pass 4: Checking reference counts Pass 5: Checking グループ summary information rootfs: ***** ファイルシステムは変更されました ***** rootfs: 5018/99840 files (4.2% non-contiguous), 163470/460800 blocks |
新しいSDから生成されたイメージを検証
早速NanoPi R2Sのシステムを新しいメディアへ入れ替え、OpenWRTが問題無く動作しました。
数日後、この新しいメディアによってオンラインで生成された、バックアップイメージを同じ要領で検証します。
|
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 |
$ gunzip -k R2S.img.gz $ ls -l -rw-r--r-- 1 user user 4026531840 Jan 22 09:36 R2S.img -rw-r--r-- 1 user user 310418270 Jan 22 09:36 R2S.img.gz $ sudo fdisk -lu R2S.img ディスク R2S.img: 3.8 GiB, 4026531840 バイト, 7864320 セクタ 単位: セクタ (1 * 512 = 512 バイト) セクタサイズ (論理 / 物理): 512 バイト / 512 バイト I/O サイズ (最小 / 推奨): 512 バイト / 512 バイト ディスクラベルのタイプ: dos ディスク識別子: 0x7ac9d3f4 デバイス 起動 開始位置 最後から セクタ サイズ Id タイプ R2S.img1 * 65536 98303 32768 16M 83 Linux R2S.img2 131072 3817471 3686400 1.8G 83 Linux $ sudo partx -v -a R2S.img パーティション: none, ディスク: R2S.img, 下限: 0, 上限: 0 ループバックデバイスとして '/dev/loop26' を使用しようとしています /dev/loop26: パーティション情報のタイプ 'dos' を検出しました range recount: max partno=2, lower=0, upper=0 /dev/loop26: パーティション #1 を追加しました /dev/loop26: パーティション #2 を追加しました $ sudo fsck -fy /dev/loop26p1 fsck from util-linux 2.31.1 e2fsck 1.44.1 (24-Mar-2018) Pass 1: Checking iノードs, blocks, and sizes Pass 2: Checking ディレクトリ structure Pass 3: Checking ディレクトリ connectivity Pass 4: Checking reference counts Pass 5: Checking グループ summary information kernel: 14/1024 files (0.0% non-contiguous), 2983/4096 blocks $ sudo fsck -fy -t ext4 /dev/loop26p2 fsck from util-linux 2.31.1 e2fsck 1.44.1 (24-Mar-2018) Pass 1: Checking iノードs, blocks, and sizes Iノード 20460, end of extent exceeds allowed value (logical block 256, physical block 206592, len 119) クリア? yes Iノード 20460, i_blocks is 2952, should be 2056. 修正? yes Pass 2: Checking ディレクトリ structurePass 3: Checking ディレクトリ connectivity -略- rootfs: ***** ファイルシステムは変更されました ***** rootfs: 5021/99840 files (4.2% non-contiguous), 165048/460800 blocks |
まだ問題点はいくつか出てくるものの、数は少ないのでOpenWRTのメジャーアップグレードまではこのまま動かそうと思います。
ちなみに、取り出した古いメディアの方も dd に掛けてみたところ、こちらはやはりイメージ検証時を遥かに上回る量のエラーと修正の量に。一応全て修復されたと言い張る実行結果ではありますが、廃棄処分するのが良さそうです。
created by Rinker
¥8,990
(2024/06/11 15:41:41時点 Amazon調べ-詳細)